#4394

Summary

The iOS caret test 'Focus is prevented after clearing the cursor' was tapping the right edge with a synthetic point-tap. A zero-radius synthetic tap never triggers iOS Safari's touch-adjustment ("fuzzy tapping") retargeting, so the bug could never reproduce and the test always passed — it did not actually guard against #4394.

This PR reworks the test to faithfully reproduce #4394's exact steps on a non-cursor thought:

1. Create thought Hello
2. Dismiss the keyboard
3. Cursor Back (swipe right) to set the cursor to null — so Hello becomes a non-cursor thought (verified editing === null before the tap)
4. Tap ~4px past the right edge, vertically centered, using a finger-sized contact area (width/height/pressure)

Mechanism

The finger-sized contact area triggers iOS Safari's touch-adjustment heuristic:

touchstart (…) tgt=DIV#thought-annotation   ← touch lands on the annotation overlay
touchend   (…) tgt=DIV#thought-annotation   ← editable's onTouchEnd never fires → no preventDefault
mousedown  (…) tgt=DIV[EDITABLE]            ← Safari retargets the synthesized mouse events into the editable
focusin        tgt=DIV[EDITABLE]            ← focus proceeds
→ *** KEYBOARD OPEN ***

Because the touch events are dispatched on the annotation (not the editable), the editable's onTouchEnd never runs to preventDefault; Safari then redirects the mouse events into the editable and focus proceeds, so the virtual keyboard incorrectly opens.

Root cause

The onMouseDown else branch does call e.preventDefault(), which blocks the native focus default of the tap — so native focus is not the vector. The keyboard opens because of a stale, never-reset offsetRef in useEditMode.ts:

• offsetRef.current is assigned when a thought that has the cursor is tapped, but it is never reset back to null.
• On the edge tap of the now-non-cursor thought, the retargeted mouseup runs onMouseUp, which reads that stale offset and calls setCaretOffset → selection.set.
• selection.set sets a DOM range inside the contentEditable, which programmatically focuses it (and opens the keyboard) even though onMouseDown preventDefaulted the native focus.

This is exactly what PR #4371 fixed by deleting onMouseUp/offsetRef and moving setCaretOffset into a guarded onMouseDown. caretFocusIsolated.ts proves this against bare DOM primitives: a reproduce fixture (mousedown preventDefault + a mouseup selection.set with a stale offset) leaks focus/keyboard, while a control fixture (no mouseup selection = post-#4371) blocks focus and keeps the keyboard down.

Expected outcome

On this pre-#4371 branch the reworked spec passes, positively demonstrating that #4394 reproduces (isKeyboardShown() returns true for a non-cursor thought). Once focus is correctly prevented for non-cursor thoughts, the assertion should be flipped to toBe(false) to convert it into a standing regression guard.

Environment: reproduces on both iOS 17 and iOS 18

The stale-offsetRef focus path is device- and version-independent code logic, and real BrowserStack devices confirm the bug reproduces on both iOS 17 and iOS 18 (the finger-sized contact area triggers the touch-adjustment retargeting on both). An earlier revision assumed the bug was iOS-18-only, but that assumption was never actually exercised on iOS 17 — the spec had been excluded from the iOS 17 device. Running it there showed the keyboard opens on iOS 17 as well.

The #4394 regression is isolated into its own spec file (src/e2e/iOS/__tests__/caretFocus.ts) and BrowserStack is configured with three capabilities:

• iPhone 15 Plus / iOS 17 — runs the entire suite except caretFocus.ts / caretFocusIsolated.ts (unchanged from before).
• iPhone 16 Pro Max / iOS 18 — runs caretFocus.ts and caretFocusIsolated.ts.
• iPhone 15 Plus / iOS 17 — runs only caretFocus.ts, to positively verify the bug is not iOS-18-specific.

This scopes the reproduction to dedicated devices and keeps the rest of the iOS suite on its original device/OS.

Notes

• Native priming tap. A priming step (a real native tap on the thought's center, then keyboard dismissal) is required so the synthetic edge-touch reliably wins the timing race that a real finger triggers on its own. It uses a native performActions tap rather than a webview element.click() because on real hardware only a native touch focuses the editable and opens the keyboard (a webview click does not, which previously caused the priming's keyboard dismissal to fail on BrowserStack). Priming while Hello has the cursor is also what leaves offsetRef.current set (and never reset) on pre-Move setCaretOffset into onMouseDown and preventAutoscrollEnd back into onFocus #4371.
• No releaseActions() is called after performActions — Safari/XCUITest does not support the DELETE /actions endpoint (the gesture helper avoids it for the same reason).
• getElementRectByScreen computes the status-bar offset per-device, so the tap coordinates map correctly across the simulator and BrowserStack hardware.